Fix homepage localization for chip labels and translations by SunayKulkarni · Pull Request #2275 · nexu-io/open-design

SunayKulkarni · 2026-05-19T14:00:26Z

Fixes #2076

Why

This PR addresses incomplete localization on the homepage in 0.8.0-preview.

While using the Chinese language setting, several homepage UI elements were still displayed in English. This was mainly due to hardcoded chip labels and missing or inconsistent translation entries, leading to a mixed-language experience.

Additionally, some direct English-to-Chinese translations resulted in vague or unclear meanings. This PR improves those cases by choosing more context-appropriate translations for better clarity and UX.

What users will see

When switching to Chinese:

Homepage category chips (Prototype, Image, Video, etc.) are properly localized
"starter" section is now consistently translated as 官方入门
Previously untranslated items (e.g. HyperFrames handling) are now consistent
Ambiguous translations have been refined to better match intended meaning
No mixed English/Chinese UI remains on the homepage

Surface area

Screenshots

Bug fix verification

Before this fix, homepage category chips (Prototype, Image, Video, etc.) showed hardcoded English labels even when the language was set to Chinese. The HyperFrames tooltip also displayed the raw English hint string ("Author HTML-based motion...") instead of the localized version. After this fix, all chip labels and tooltips render correct zh-CN strings with no English fallbacks remaining on the homepage.

Validation

Verified changes locally using pnpm dev
Switched language to Chinese and confirmed all homepage elements are localized
Ensured no raw i18n keys or English fallbacks remain in homepage UI

lefarcen · 2026-05-19T14:04:59Z

Hi @SunayKulkarni — thanks for picking up #2076 and for keeping the fix focused on the homepage chip labels. I’ve requested @nettee for the pool review.

Heads-up: PR #2205 is also open in the same zh-CN localization area and touches apps/web/src/components/HomeHero.tsx, apps/web/src/components/home-hero/chips.ts, and apps/web/src/i18n/locales/zh-CN.ts. That one is a broader localization pass, while this PR is the focused homepage fix for #2076; you and @mcncarl may want to compare approaches so the overlapping pieces don’t duplicate effort. The maintainer team will decide how to land or consolidate them.

nettee

I found two issues to address before this lands: the top chip bar still leaks an English tooltip in zh-CN, and the new labelKey path currently bypasses the typed i18n keys.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-19T14:08:26Z

            disabled={pluginsLoading || isPending || pendingPluginId !== null}
            aria-selected={isActive}
-            title={chip.hint ?? chip.label}
+            title={chip.hint ?? t(chip.labelKey as any)}


This still leaves the HyperFrames tooltip untranslated in zh-CN. chip.hint comes from the hardcoded English string in apps/web/src/components/home-hero/chips.ts, so hovering the top-row HyperFrames tab shows Author HTML-based motion... even though homeHero.chip.hyperframesHint already exists and the lower rail uses it via homeHeroChipTitle(). Since this PR’s goal is to remove mixed-language homepage UI, please route the top tab bar through the same localized title helper (or otherwise translate the hint source) instead of reading chip.hint directly.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-19T14:08:26Z

  {
    id: 'create-plugin',
-    label: 'Create plugin',
+    labelKey: 'homeHero.chip.create-plugin',


The new labelKey field already contains an invalid key here: the locale dictionaries and apps/web/src/i18n/types.ts define homeHero.chip.createPlugin, not homeHero.chip.create-plugin. Right now that mismatch is hidden because labelKey is typed as plain string and the caller does t(chip.labelKey as any), so the compiler can’t catch bad keys. Please switch this entry to the existing createPlugin key and tighten labelKey to a typed i18n-key union (then drop the as any cast) so future localization regressions fail at compile time.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

SunayKulkarni · 2026-05-19T14:35:37Z

Good catch, thanks!

Fixed the incorrect key (create-plugin → createPlugin)
Removed the as any cast so invalid keys are no longer hidden
Updated the top tab bar to use homeHeroChipTitle(chip, t) so tooltips are fully localized (including HyperFrames)

Let me know if anything else needs adjustment.

nettee

I rechecked the follow-up head and the visible zh-CN homepage regressions are fixed. One maintainability issue remains in the new translation-key path.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-19T14:42:14Z

 export interface HomeHeroChip {
  id: string;
-  label: string;
+  labelKey: string;


labelKey is still widened to plain string, so this follow-up does not actually restore compile-time protection for chip translation keys. useT() only accepts keyof Dict in apps/web/src/i18n/index.tsx, but this metadata shape now allows any arbitrary string, which is how the earlier homeHero.chip.create-plugin typo slipped in unnoticed until runtime. That matters because future chip additions can reintroduce missing-translation regressions even though this PR moved the UI over to labelKey. Please type this field as a real i18n key (for example keyof Dict, or a narrower HomeHeroChipLabelKey union derived from Dict) and import that type here so bad keys fail during development instead of shipping to users.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee

I rechecked the current head and the visible zh-CN homepage regressions look fixed. One maintainability issue remains in the new chip-label metadata path.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-19T15:28:05Z

 export interface HomeHeroChip {
  id: string;
-  label: string;
+  labelKey: keyof Dict;


labelKey is now type-safe here, but the lower rail still does not read it: RailGroup renders homeHeroChipLabel(chip.id, t) in apps/web/src/components/HomeHero.tsx:1587, and homeHeroChipTitle() also switches on chip.id for the migrate chips at apps/web/src/components/HomeHero.tsx:1616-1619. That means the new metadata entries you changed here (create-plugin, figma, folder, template) are not actually the source of truth for the labels/tooltips users see in that rail. This matters because future homepage i18n edits can compile cleanly while silently updating only one of the two paths. Please either drive both rail labels/titles from chip metadata (for example labelKey plus a typed hint/title key) or keep the switch helpers as the single source of truth and drop the unused migrate-chip labelKey fields.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee

One blocking issue remains in the current head: the chip metadata type now requires labelKey, but the same patch removes that property from every migrate-chip entry, so this change no longer satisfies the declared HomeHeroChip contract.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-19T16:06:07Z

 export interface HomeHeroChip {
  id: string;
-  label: string;
+  labelKey: keyof Dict;


HomeHeroChip still requires labelKey here, but this patch removes that property from the create-plugin, figma, folder, and template entries below. That leaves HOME_HERO_CHIPS out of sync with its declared ReadonlyArray<HomeHeroChip> type, so the i18n-safety follow-up now turns into a type/build break instead of a clean refactor. Please either keep labelKey on those migrate chips, or split the model into separate create/migrate chip types so only the create chips are required to carry labelKey.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

SunayKulkarni · 2026-05-19T17:13:02Z

Restored labelKey on the migrate chips to satisfy the HomeHeroChip type

Kept the switch-based helpers as the current source of truth for rendering (since the lower rail still uses them)

I see the concern about multiple sources of truth here. With labelKey restored, the migrate chips now carry the key but still rely on the helpers for labels/tooltips.

For now I’ve kept this approach to avoid breaking the contract and keep the change scoped.

nettee

I rechecked the current head: the chip labels/tooltips now route through the localized helpers, and the zh-CN starter copy is consistent. One follow-up regression-coverage gap remains.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-19T17:18:30Z

            disabled={pluginsLoading || isPending || pendingPluginId !== null}
            aria-selected={isActive}
-            title={chip.hint ?? chip.label}
+            title={homeHeroChipTitle(chip, t)}


apps/web/src/components/HomeHero.tsx:1534-1536 adds the localized label/title path, but there still is no regression test covering that zh-CN behavior. apps/web/tests/components/HomeHero.rail.test.tsx currently only checks that each chip renders, routes clicks, and toggles state; it never asserts translated text or tooltips, so the earlier labelKey typo and English HyperFrames tooltip both would have passed the suite. Because this PR's goal is to eliminate mixed-language homepage UI, please extend that rail test to render under zh-CN and assert at least one translated create-chip label plus the localized HyperFrames tooltip.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee

I rechecked the current head: the zh-CN chip labels/tooltips regression and the new locale-specific rail test both look good. One non-blocking maintainability issue remains in the chip metadata path.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-19T18:02:52Z

  {
    id: 'create-plugin',
-    label: 'Create plugin',
+    labelKey: 'homeHero.chip.createPlugin',


labelKey is type-safe now, but the migrate-chip metadata you changed here still is not the source of truth for what the homepage renders. RailGroup still reads homeHeroChipLabel(chip.id, t) in apps/web/src/components/HomeHero.tsx:1587, and homeHeroChipTitle() still switches on chip.id for these same create-plugin / figma / folder / template entries at apps/web/src/components/HomeHero.tsx:1616-1619. That matters because a future homepage i18n edit can update HOME_HERO_CHIPS and assume the UI changed, while the rendered label/tooltip keeps coming from the separate switch tables. Please either derive both label and tooltip from the chip metadata (for example labelKey plus a typed hintKey) or split the chip model so migrate chips do not carry localized fields that the renderer ignores.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

SunayKulkarni · 2026-05-19T19:10:16Z

I’ve taken the second approach here and split the chip model into create/migrate variants, so migrate chips no longer carry localized fields like labelKey that the renderer doesn’t actually consume.

With this change, the data model now reflects the current rendering path more accurately — create chips derive their labels from metadata, while migrate chips continue to use the existing switch-based helpers (homeHeroChipLabel / homeHeroChipTitle). This avoids the mismatch where updates to HOME_HERO_CHIPS could imply UI changes that wouldn’t actually be reflected.

I’ve kept the switch helpers as the source of truth for migrate chips to keep the scope of this PR focused and avoid touching multiple rendering paths. That said, I agree that moving both label and tooltip fully to metadata (e.g., labelKey + a typed hintKey) would be a cleaner long-term direction, and I’d be happy to follow up with that in a separate PR if preferred.

nettee

@SunayKulkarni I rechecked the current head and reviewed the changed ranges in HomeHero, the chip metadata split, the zh-CN copy update, and the new rail regression test. The localized label/title path now lines up with the current create-vs-migrate rendering split, and the added zh-CN test covers the regression this PR is fixing. Nice cleanup getting this homepage pass into a consistent state.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

lefarcen · 2026-05-22T11:04:09Z

Hey @SunayKulkarni — you and @nettee did a solid job working through that chip-model split and the test coverage, and the final approval landed three days ago. 🎉

One thing standing between this and a merge: the branch now has a conflict with main (likely overlapping with #2205, which is also open and touches the same zh-CN / chip files). Could you do a quick rebase onto the latest main? Once that conflict is cleared, this is ready for the maintainer's call.

Let me know if anything comes up during the rebase — happy to help scope what to watch for.

…dering

nettee

Two blocking regressions remain in the current head: the new create-chip label path blanks the existing live-artifact tab, and the newly added folder chip is not wired through the current action/rendering flow.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-22T12:26:48Z

+            aria-selected={isActive}
+            title={homeHeroChipTitle(chip, t)}
+          >
+         <span>{chip.group === 'create' ? t(chip.labelKey) : homeHeroChipLabel(chip.id, t)}</span>


TypeTabBar now renders create chips from chip.labelKey, but HOME_HERO_CHIPS still has an existing create-group entry (live-artifact in apps/web/src/components/home-hero/chips.ts:104-108) that only carries the old label/hint fields. Because this line takes the create branch for that chip, t(chip.labelKey) receives undefined, so the top-row live-artifact tab loses its visible label even though homeHeroChipLabel() already has the correct i18n key at apps/web/src/components/HomeHero.tsx:2586. That breaks the homepage UI this PR is trying to localize. Please either finish migrating every create chip to labelKey (for example labelKey: "homeHero.chip.liveArtifact", plus a localized hint path) or keep this renderer on homeHeroChipLabel(chip.id, t) until the create-chip metadata migration is complete.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-22T12:26:48Z

+    icon: 'folder',
+    group: 'migrate',
+    hint: 'Import an existing local folder and continue editing.',
+    action: { kind: 'import-folder' },


This adds a new folder chip with action: { kind: import-folder }, but the rest of the changed flow still treats folder as unsupported. ChipAction in this same file does not define import-folder, HomeView only switches apply-scenario / apply-figma-migration / create-plugin / open-template-picker (apps/web/src/components/HomeView.tsx:1089-1166), and the current rail test still asserts both queryByTestId("home-hero-rail-folder") === null and findChip("folder") === undefined (apps/web/tests/components/HomeHero.rail.test.tsx:194-208). That means this PR adds a homepage chip that neither type-checks nor has a working click path. Please either drop the folder entry from this bugfix PR, or fully wire import-folder through the action union, renderer/title helpers, dispatcher, and tests before landing it.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

…act to ChipScenarioPluginId

SunayKulkarni · 2026-05-22T13:09:15Z

Fixed two chips.ts type errors (removed unused label from CreateChip interface, added example-live-artifact to ChipScenarioPluginId). All rail tests passing.

nettee

I reviewed the current head's changed ranges and one merge-safe maintainability issue remains. I also couldn't rerun the web checks in this checkout because node_modules are absent.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-22T13:49:26Z

+interface TypeTabBarProps {
+  activeChipId: string | null;
+  pendingChipId: string | null;
+  pendingPluginId: string | null;
+  pluginsLoading: boolean;
+  onPickChip: (chip: HomeHeroChip) => void;
+}
+
+function TypeTabBar({
+  activeChipId,
+  pendingChipId,
+  pendingPluginId,
+  pluginsLoading,
+  onPickChip,
+}: TypeTabBarProps) {
+  const chips = useMemo(() => chipsForGroup('create'), []);
+  const t = useT();
+  return (
+    <div className="home-hero__type-tabs" role="tablist" aria-label="Output type">
+      {chips.map((chip) => {
+        const isActive = activeChipId === chip.id;
+        const isPending = pendingChipId === chip.id;
+        const cls = ['home-hero__type-tab'];
+        if (isActive) cls.push('is-active');
+        if (isPending) cls.push('is-pending');
+        return (
+          <button
+            key={chip.id}
+            type="button"
+            role="tab"
+            className={cls.join(' ')}
+            data-chip-id={chip.id}
+            data-testid={`home-hero-rail-${chip.id}`}
+            onClick={() => onPickChip(chip)}
+            disabled={pluginsLoading || isPending || pendingPluginId !== null}
+            aria-selected={isActive}
+            title={homeHeroChipTitle(chip, t)}
+          >
+         <span>{homeHeroChipLabel(chip.id, t)}</span>
+          </button>
+        );
+      })}
+    </div>
+  );
+}


TypeTabBar is introduced here, but the live HomeHero tab row is still rendered through RailGroup rather than this new component. That leaves these changed lines as dead duplicate UI code, and they have already drifted from the real path (for example the hard-coded English aria-label and simpler markup here vs the localized/accessibility-aware RailGroup path below). This matters because a future homepage i18n or accessibility fix can land in TypeTabBar and never reach users. Please either remove TypeTabBar, or make it the single tab renderer and delete the overlapping tab logic from RailGroup so there is only one code path to maintain.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

lefarcen

Hey @SunayKulkarni! The Why / What users will see writeup is clear, the Surface area checklist is filled in, and your Validation steps show you tested locally — solid context for reviewers.\n\nOne small gap: ## Bug fix verification is still just a placeholder (-). Since this carries the type/bugfix label, could you add a couple of lines on what the regression looked like before this fix and how you confirmed it is resolved? Even a short note like "homepage chips showed English text when Chinese language was set; after this fix all chips display correct zh-CN strings" alongside the existing Validation steps is enough.

nettee

I reviewed the current head's changed ranges and found one merge-safe maintainability follow-up in the new chip metadata path.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-22T15:49:41Z

-  label: string;
-  icon: IconName;
-  group: ChipGroup;
+  labelKey: keyof Dict;


This change makes labelKey part of the new CreateChip contract, but the homepage renderer still does not consume it: RailGroup continues to render homeHeroChipLabel(chip.id, t) in apps/web/src/components/HomeHero.tsx, and the new zh-CN test only asserts that switch-based output. That leaves two sources of truth for the same label, so a future edit can update HOME_HERO_CHIPS and assume the UI changed even though the rendered copy still comes from the separate switch table. Please either render create-chip labels directly from chip.labelKey (and extend the test to cover that path), or remove labelKey from this model until the UI actually uses it.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

…le source of truth

SunayKulkarni · 2026-05-22T16:08:56Z

Removed labelKey from CreateChip interface and all create-chip entries. The Dict import was also removed since it's no longer referenced. homeHeroChipLabel(chip.id, t) remains the single source of truth for rendered labels. The 167 TS errors from tsc --noEmit are pre-existing on main and unrelated to this PR (they're in analytics/events.ts, MemorySection.tsx, etc.).

nettee

I reviewed the current head's changed ranges and the homepage localization fixes look correct, but one regression-coverage gap remains in the new zh-CN rail test.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-22T16:16:15Z

    });
  });
+
+  it('renders localized chip labels and tooltips in zh-CN', () => {


This regression test only asserts one always-visible create-chip label (prototype) and one tooltip (hyperframes), and it never opens the More shortcuts menu. That means the zh-CN copy for the changed migrate shortcuts (create-plugin, figma, template) can regress without this suite failing, even though the PR body says no mixed English homepage UI remains. Please extend this test to open home-hero-shortcuts-trigger under zh-CN and assert the localized labels/titles for the shortcut chips as well, so the homepage-localization guarantee is covered across both rail rows.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

…shortcuts menu

nettee

I reviewed the current head's changed ranges and the homepage localization fixes look correct overall, but one regression-coverage gap remains in the new zh-CN rail test.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee · 2026-05-23T18:38:30Z

+    </I18nProvider>
+  );
+
+  // Prototype chip label should be zh-CN


This zh-CN regression test still skips the other always-visible create chip, live-artifact. The current homepage renderer localizes that chip through homeHeroChipLabel() / homeHeroChipTitle() (homeHero.chip.liveArtifact and homeHero.chip.liveArtifactHint), and this same PR also touches its chip contract by adding example-live-artifact to ChipScenarioPluginId in apps/web/src/components/home-hero/chips.ts. Because the assertions here only cover prototype, hyperframes, and the migrate shortcuts, a future regression in the live-artifact zh-CN label or tooltip would still pass even though the PR body says no mixed-language homepage UI remains. Please add home-hero-rail-live-artifact text and title assertions in this test so the visible create-chip set is covered end to end.
_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

nettee

@SunayKulkarni I rechecked the current head's changed ranges in , the zh-CN homepage copy, and the added rail regression test. The scenario wiring now matches the live chip catalog, and the zh-CN assertions cover the visible create chips plus the shortcut menu labels/tooltips this PR set out to localize. Nice job closing out the homepage mixed-language regression.

_{🔁 Powered by Looper · runner=reviewer · agent=opencode · An autonomous AI dev team for your GitHub repos.}

lefarcen requested a review from nettee May 19, 2026 14:02

lefarcen added size/S PR changes 20-100 lines risk/medium Medium risk: regular code changes type/bugfix Bug fix labels May 19, 2026

lefarcen mentioned this pull request May 19, 2026

[codex] Improve Simplified Chinese UI localization #2205

Open

9 tasks

nettee requested changes May 19, 2026

View reviewed changes

lefarcen requested a review from nettee May 19, 2026 14:41

nettee reviewed May 19, 2026

View reviewed changes

nettee requested changes May 19, 2026

View reviewed changes

nettee reviewed May 19, 2026

View reviewed changes

lefarcen requested a review from nettee May 19, 2026 18:00

nettee reviewed May 19, 2026

View reviewed changes

nettee approved these changes May 19, 2026

View reviewed changes

SunayKulkarni added 7 commits May 22, 2026 17:42

Fix incomplete homepage localization (chip labels + translations)

7459aba

Fix i18n key mismatch and remove unsafe cast; localize tooltips

f026e56

Enforce type-safe i18n keys for HomeHero chips

0723732

Remove unused labelKey for migrate chips to avoid duplicate i18n sources

6244913

Restore labelKey for migrate chips to satisfy HomeHeroChip type

bba7388

Add zh-CN localization test for HomeHero rail labels and tooltips

7f9a7cb

Refactor HomeHeroChip into create/migrate union and fix type-safe ren…

26fa6d9

…dering

SunayKulkarni force-pushed the fix-homepage-i18n branch from a6bfd6f to 26fa6d9 Compare May 22, 2026 12:13

nettee requested changes May 22, 2026

View reviewed changes

Fix type errors: remove label from CreateChip, add example-live-artif…

16ab5d8

…act to ChipScenarioPluginId

nettee reviewed May 22, 2026

View reviewed changes

lefarcen reviewed May 22, 2026

View reviewed changes

Remove dead TypeTabBar component; RailGroup is the single tab renderer

9199903

nettee reviewed May 22, 2026

View reviewed changes

Remove unused labelKey from CreateChip; homeHeroChipLabel is the sing…

465819d

…le source of truth

nettee reviewed May 22, 2026

View reviewed changes

Extend zh-CN rail test to cover migrate chip labels and tooltips via …

0c53dcf

…shortcuts menu

nettee reviewed May 23, 2026

View reviewed changes

Add live-artifact zh-CN label and tooltip assertions to rail test

cfde794

nettee approved these changes May 23, 2026

View reviewed changes

Conversation

SunayKulkarni commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

What users will see

Surface area

Screenshots

Bug fix verification

Validation

Uh oh!

lefarcen commented May 19, 2026

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SunayKulkarni commented May 19, 2026

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SunayKulkarni commented May 19, 2026

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SunayKulkarni commented May 19, 2026

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

lefarcen commented May 22, 2026

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SunayKulkarni commented May 22, 2026

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lefarcen left a comment

Choose a reason for hiding this comment

Uh oh!

nettee left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SunayKulkarni commented May 22, 2026

Uh oh!

nettee left a comment

SunayKulkarni commented May 19, 2026 •

edited

Loading